Гексагональна архітектура: Практичний посібник з портів та адаптерів

У світі розробки програмного забезпечення, що постійно розвивається, створення надійних, зручних у супроводі та тестованих застосунків є першочерговим завданням. Гексагональна архітектура, також відома як «Порти та адаптери», — це архітектурний патерн, що вирішує ці проблеми шляхом відокремлення основної бізнес-логіки застосунку від його зовнішніх залежностей. Цей посібник має на меті надати всебічне розуміння гексагональної архітектури, її переваг та практичних стратегій реалізації для розробників у всьому світі.

Що таке гексагональна архітектура?

Гексагональна архітектура, термін якої ввів Алістер Коберн, обертається навколо ідеї ізоляції основної бізнес-логіки застосунку від зовнішнього світу. Ця ізоляція досягається за допомогою портів та адаптерів.

• Ядро (Застосунок): Представляє серце вашого застосунку, містить бізнес-логіку та доменні моделі. Воно має бути незалежним від будь-якої конкретної технології чи фреймворку.
• Порти: Визначають інтерфейси, які ядро застосунку використовує для взаємодії із зовнішнім світом. Це абстрактні визначення того, як застосунок взаємодіє із зовнішніми системами, такими як бази даних, користувацькі інтерфейси або черги повідомлень. Порти можуть бути двох типів:
  • Рушійні (Первинні) порти: Визначають інтерфейси, через які зовнішні актори (наприклад, користувачі, інші застосунки) можуть ініціювати дії в ядрі застосунку.
  • Ведені (Вторинні) порти: Визначають інтерфейси, які ядро застосунку використовує для взаємодії із зовнішніми системами (наприклад, базами даних, чергами повідомлень).
• Адаптери: Реалізують інтерфейси, визначені портами. Вони діють як перекладачі між ядром застосунку та зовнішніми системами. Існує два типи адаптерів:
  • Рушійні (Первинні) адаптери: Реалізують рушійні порти, перетворюючи зовнішні запити на команди або запити, які ядро застосунку може зрозуміти. Прикладами є компоненти користувацького інтерфейсу (наприклад, вебконтролери), інтерфейси командного рядка або слухачі черги повідомлень.
  • Ведені (Вторинні) адаптери: Реалізують ведені порти, перетворюючи запити ядра застосунку на конкретні взаємодії із зовнішніми системами. Прикладами є об'єкти доступу до даних, продюсери черги повідомлень або клієнти API.

Уявіть це так: ядро застосунку знаходиться в центрі, оточене гексагональною оболонкою. Порти — це точки входу та виходу на цій оболонці, а адаптери підключаються до цих портів, з'єднуючи ядро із зовнішнім світом.

Ключові принципи гексагональної архітектури

Ефективність гексагональної архітектури ґрунтується на кількох ключових принципах:

• Інверсія залежностей: Ядро застосунку залежить від абстракцій (портів), а не від конкретних реалізацій (адаптерів). Це основний принцип SOLID.
• Чіткі інтерфейси: Порти чітко визначають межі між ядром та зовнішнім світом, сприяючи підходу до інтеграції на основі контрактів.
• Тестованість: Завдяки відокремленню ядра від зовнішніх залежностей стає легше тестувати бізнес-логіку в ізоляції, використовуючи макети реалізацій портів.
• Гнучкість: Адаптери можна замінювати без впливу на ядро застосунку, що дозволяє легко адаптуватися до мінливих технологій або вимог. Уявіть, що потрібно перейти з MySQL на PostgreSQL; потрібно змінити лише адаптер бази даних.

Переваги використання гексагональної архітектури

Застосування гексагональної архітектури пропонує численні переваги:

• Покращена тестованість: Розділення відповідальностей значно спрощує написання модульних тестів для основної бізнес-логіки. Мокування портів дозволяє ізолювати ядро та ретельно його тестувати, не покладаючись на зовнішні системи. Наприклад, модуль обробки платежів можна протестувати, мокуючи порт платіжного шлюзу, симулюючи успішні та невдалі транзакції без фактичного підключення до реального шлюзу.
• Підвищена зручність супроводу: Зміни у зовнішніх системах або технологіях мають мінімальний вплив на ядро застосунку. Адаптери діють як ізоляційні шари, захищаючи ядро від зовнішньої нестабільності. Розглянемо сценарій, коли сторонній API, що використовується для надсилання SMS-повідомлень, змінює свій формат або метод автентифікації. Потрібно оновити лише SMS-адаптер, залишаючи ядро застосунку недоторканим.
• Посилена гнучкість: Адаптери можна легко замінювати, що дозволяє адаптуватися до нових технологій або вимог без значного рефакторингу. Це сприяє експериментам та інноваціям. Компанія може вирішити перенести своє сховище даних з традиційної реляційної бази даних на NoSQL. Завдяки гексагональній архітектурі потрібно замінити лише адаптер бази даних, мінімізуючи вплив на ядро застосунку.
• Зменшення зв'язаності: Ядро застосунку відокремлене від зовнішніх залежностей, що призводить до більш модульної та згуртованої конструкції. Це робить кодову базу легшою для розуміння, модифікації та розширення.
• Незалежна розробка: Різні команди можуть працювати над ядром застосунку та адаптерами незалежно, що сприяє паралельній розробці та швидшому виходу на ринок. Наприклад, одна команда може зосередитися на розробці основної логіки обробки замовлень, тоді як інша команда створює користувацький інтерфейс та адаптери баз даних.

Реалізація гексагональної архітектури: Практичний приклад

Проілюструймо реалізацію гексагональної архітектури на спрощеному прикладі системи реєстрації користувачів. Для ясності ми будемо використовувати гіпотетичну мову програмування (схожу на Java або C#).

1. Визначення ядра (Застосунку)

Ядро застосунку містить бізнес-логіку для реєстрації нового користувача.

// Core/UserService.java (або UserService.cs)
public class UserService {
    private final UserRepository userRepository;
    private final PasswordHasher passwordHasher;
    private final UserValidator userValidator;

    public UserService(UserRepository userRepository, PasswordHasher passwordHasher, UserValidator userValidator) {
        this.userRepository = userRepository;
        this.passwordHasher = passwordHasher;
        this.userValidator = userValidator;
    }

    public Result<User, String> registerUser(String username, String password, String email) {
        // Валідація введених даних користувача
        ValidationResult validationResult = userValidator.validate(username, password, email);
        if (!validationResult.isValid()) {
            return Result.failure(validationResult.getErrorMessage());
        }

        // Перевірка, чи користувач вже існує
        if (userRepository.findByUsername(username).isPresent()) {
            return Result.failure("Користувач з таким іменем вже існує");
        }

        // Хешування пароля
        String hashedPassword = passwordHasher.hash(password);

        // Створення нового користувача
        User user = new User(username, hashedPassword, email);

        // Збереження користувача в репозиторії
        userRepository.save(user);

        return Result.success(user);
    }
}

2. Визначення портів

Ми визначаємо порти, які ядро застосунку використовує для взаємодії із зовнішнім світом.

// Ports/UserRepository.java (або UserRepository.cs)
public interface UserRepository {
    Optional<User> findByUsername(String username);
    void save(User user);
}

// Ports/PasswordHasher.java (або PasswordHasher.cs)
public interface PasswordHasher {
    String hash(String password);
}

//Ports/UserValidator.java (або UserValidator.cs)
public interface UserValidator{
  ValidationResult validate(String username, String password, String email);
}

//Ports/ValidationResult.java (або ValidationResult.cs)
public interface ValidationResult{
  boolean isValid();
  String getErrorMessage();
}

3. Визначення адаптерів

Ми реалізуємо адаптери, які з'єднують ядро застосунку з конкретними технологіями.

// Adapters/DatabaseUserRepository.java (або DatabaseUserRepository.cs)
public class DatabaseUserRepository implements UserRepository {
    private final DatabaseConnection databaseConnection;

    public DatabaseUserRepository(DatabaseConnection databaseConnection) {
        this.databaseConnection = databaseConnection;
    }

    @Override
    public Optional<User> findByUsername(String username) {
        // Реалізація з використанням JDBC, JPA або іншої технології доступу до бази даних
        // ...
        return Optional.empty(); // Заглушка
    }

    @Override
    public void save(User user) {
        // Реалізація з використанням JDBC, JPA або іншої технології доступу до бази даних
        // ...
    }
}

// Adapters/BCryptPasswordHasher.java (або BCryptPasswordHasher.cs)
public class BCryptPasswordHasher implements PasswordHasher {
    @Override
    public String hash(String password) {
        // Реалізація з використанням бібліотеки BCrypt
        // ...
        return "hashedPassword"; //Заглушка
    }
}

//Adapters/SimpleUserValidator.java (або SimpleUserValidator.cs)
public class SimpleUserValidator implements UserValidator {
  @Override
  public ValidationResult validate(String username, String password, String email){
    //Проста логіка валідації
     if (username == null || username.isEmpty()) {
            return new SimpleValidationResult(false, "Ім'я користувача не може бути порожнім");
        }
        if (password == null || password.length() < 8) {
            return new SimpleValidationResult(false, "Пароль має містити щонайменше 8 символів");
        }
        if (email == null || !email.contains("@")) {
            return new SimpleValidationResult(false, "Неправильний формат електронної пошти");
        }

        return new SimpleValidationResult(true, null);
  }
}

//Adapters/SimpleValidationResult.java (або SimpleValidationResult.cs)
public class SimpleValidationResult implements ValidationResult {
  private final boolean valid;
  private final String errorMessage;

    public SimpleValidationResult(boolean valid, String errorMessage) {
        this.valid = valid;
        this.errorMessage = errorMessage;
    }
  @Override
  public boolean isValid(){
    return valid;
  }

  @Override
  public String getErrorMessage(){
    return errorMessage;
  }
}



//Adapters/WebUserController.java (або WebUserController.cs)
//Рушійний адаптер - обробляє запити з вебу
public class WebUserController {
    private final UserService userService;

    public WebUserController(UserService userService) {
        this.userService = userService;
    }

    public String registerUser(String username, String password, String email) {
        Result<User, String> result = userService.registerUser(username, password, email);
        if (result.isSuccess()) {
            return "Реєстрація успішна!";
        } else {
            return "Реєстрація не вдалася: " + result.getFailure();
        }
    }
}

4. Композиція

З'єднуємо все разом. Зауважте, що ця композиція (впровадження залежностей) зазвичай відбувається в точці входу застосунку або в контейнері впровадження залежностей.

//Головний клас або конфігурація впровадження залежностей
public class Main {
    public static void main(String[] args) {
        // Створення екземплярів адаптерів
        DatabaseConnection databaseConnection = new DatabaseConnection("jdbc:mydb://localhost:5432/users", "user", "password");
        DatabaseUserRepository userRepository = new DatabaseUserRepository(databaseConnection);
        BCryptPasswordHasher passwordHasher = new BCryptPasswordHasher();
        SimpleUserValidator userValidator = new SimpleUserValidator();

        // Створення екземпляра ядра застосунку, впроваджуючи адаптери
        UserService userService = new UserService(userRepository, passwordHasher, userValidator);

        //Створення рушійного адаптера та підключення його до сервісу
        WebUserController userController = new WebUserController(userService);

        //Тепер ви можете обробляти запити на реєстрацію користувача через userController
        String result = userController.registerUser("john.doe", "P@sswOrd123", "john.doe@example.com");
        System.out.println(result);
    }
}



//DatabaseConnection - це простий клас лише для демонстраційних цілей
class DatabaseConnection {
    private String url;
    private String username;
    private String password;

    public DatabaseConnection(String url, String username, String password) {
        this.url = url;
        this.username = username;
        this.password = password;
    }

    // ... методи для підключення до бази даних (не реалізовані для стислості)
}

//Клас Result (подібний до Either у функціональному програмуванні)
class Result<T, E> {
    private final T success;
    private final E failure;
    private final boolean isSuccess;

    private Result(T success, E failure, boolean isSuccess) {
        this.success = success;
        this.failure = failure;
        this.isSuccess = isSuccess;
    }

    public static <T, E> Result<T, E> success(T value) {
        return new Result<>(value, null, true);
    }

    public static <T, E> Result<T, E> failure(E error) {
        return new Result<>(null, error, false);
    }

    public boolean isSuccess() {
        return isSuccess;
    }

    public T getSuccess() {
        if (!isSuccess) {
            throw new IllegalStateException("Результат є невдалим");
        }
        return success;
    }

    public E getFailure() {
        if (isSuccess) {
            throw new IllegalStateException("Результат є успішним");
        }
        return failure;
    }
}

class User {
    private String username;
    private String password;
    private String email;

    public User(String username, String password, String email) {
        this.username = username;
        this.password = password;
        this.email = email;
    }

    // геттери та сеттери (пропущені для стислості)

}

Пояснення:

• UserService представляє ядро бізнес-логіки. Він залежить від інтерфейсів UserRepository, PasswordHasher та UserValidator (портів).
• DatabaseUserRepository, BCryptPasswordHasher та SimpleUserValidator є адаптерами, що реалізують відповідні порти з використанням конкретних технологій (бази даних, BCrypt та базової логіки валідації).
• WebUserController — це рушійний адаптер, який обробляє вебзапити та взаємодіє з UserService.
• Головний метод компонує застосунок, створюючи екземпляри адаптерів і впроваджуючи їх у ядро застосунку.

Додаткові аспекти та найкращі практики

Хоча основні принципи гексагональної архітектури є простими, слід пам'ятати про деякі додаткові аспекти:

• Вибір правильної гранулярності для портів: Визначення відповідного рівня абстракції для портів є вирішальним. Занадто дрібнозернисті порти можуть призвести до непотрібної складності, тоді як занадто грубозернисті можуть обмежити гнучкість. Розглядайте компроміси між простотою та адаптивністю при визначенні ваших портів.
• Управління транзакціями: При роботі з кількома зовнішніми системами забезпечення транзакційної узгодженості може бути складним. Розгляньте можливість використання технік управління розподіленими транзакціями або реалізації компенсуючих транзакцій для підтримки цілісності даних. Наприклад, якщо реєстрація користувача передбачає створення облікового запису в окремій системі білінгу, вам потрібно переконатися, що обидві операції виконуються успішно або зазнають невдачі разом.
• Обробка помилок: Впроваджуйте надійні механізми обробки помилок для коректного реагування на збої в зовнішніх системах. Використовуйте автоматичні вимикачі або механізми повторних спроб, щоб запобігти каскадним збоям. Коли адаптер не може підключитися до бази даних, застосунок повинен коректно обробити помилку і, можливо, повторити спробу підключення або надати користувачеві інформативне повідомлення про помилку.
• Стратегії тестування: Використовуйте комбінацію модульних, інтеграційних та наскрізних тестів для забезпечення якості вашого застосунку. Модульні тести повинні фокусуватися на основній бізнес-логіці, тоді як інтеграційні тести повинні перевіряти взаємодію між ядром та адаптерами.
• Фреймворки впровадження залежностей: Використовуйте фреймворки впровадження залежностей (наприклад, Spring, Guice) для управління залежностями між компонентами та спрощення композиції застосунку. Ці фреймворки автоматизують процес створення та впровадження залежностей, зменшуючи кількість шаблонного коду та покращуючи зручність супроводу.
• CQRS (Command Query Responsibility Segregation): Гексагональна архітектура добре поєднується з CQRS, де ви розділяєте моделі читання та запису вашого застосунку. Це може ще більше покращити продуктивність та масштабованість, особливо в складних системах.

Реальні приклади використання гексагональної архітектури

Багато успішних компаній та проєктів застосували гексагональну архітектуру для створення надійних та зручних у супроводі систем:

• Платформи електронної комерції: Платформи електронної комерції часто використовують гексагональну архітектуру для відокремлення основної логіки обробки замовлень від різних зовнішніх систем, таких як платіжні шлюзи, постачальники послуг доставки та системи управління запасами. Це дозволяє їм легко інтегрувати нові способи оплати або варіанти доставки, не порушуючи основну функціональність.
• Фінансові застосунки: Фінансові застосунки, такі як банківські системи та торгові платформи, виграють від тестованості та зручності супроводу, які пропонує гексагональна архітектура. Основна фінансова логіка може бути ретельно протестована в ізоляції, а адаптери можуть використовуватися для підключення до різних зовнішніх сервісів, таких як постачальники ринкових даних та клірингові палати.
• Мікросервісні архітектури: Гексагональна архітектура природно підходить для мікросервісних архітектур, де кожен мікросервіс представляє обмежений контекст з власною основною бізнес-логікою та зовнішніми залежностями. Порти та адаптери забезпечують чіткий контракт для зв'язку між мікросервісами, сприяючи слабкій зв'язаності та незалежному розгортанню.
• Модернізація застарілих систем: Гексагональну архітектуру можна використовувати для поступової модернізації застарілих систем, обгортаючи існуючий код в адаптери та впроваджуючи нову основну логіку за портами. Це дозволяє поступово замінювати частини застарілої системи, не переписуючи весь застосунок.

Виклики та компроміси

Хоча гексагональна архітектура пропонує значні переваги, важливо визнати пов'язані з нею виклики та компроміси:

• Підвищена складність: Реалізація гексагональної архітектури може вводити додаткові шари абстракції, що може збільшити початкову складність кодової бази.
• Крива навчання: Розробникам може знадобитися час, щоб зрозуміти концепції портів та адаптерів і як їх ефективно застосовувати.
• Потенціал для надмірної інженерії: Важливо уникати надмірної інженерії, створюючи непотрібні порти та адаптери. Починайте з простого дизайну і поступово додавайте складність за потреби.
• Міркування щодо продуктивності: Додаткові шари абстракції потенційно можуть внести деякі накладні витрати на продуктивність, хоча в більшості застосунків вони зазвичай незначні.

Важливо ретельно оцінити переваги та виклики гексагональної архітектури в контексті вимог вашого конкретного проєкту та можливостей команди. Це не срібна куля, і вона може бути не найкращим вибором для кожного проєкту.

Висновок

Гексагональна архітектура, з її акцентом на порти та адаптери, надає потужний підхід до створення зручних у супроводі, тестованих та гнучких застосунків. Відокремлюючи основну бізнес-логіку від зовнішніх залежностей, вона дозволяє вам легко адаптуватися до мінливих технологій та вимог. Хоча існують виклики та компроміси, які слід враховувати, переваги гексагональної архітектури часто переважають витрати, особливо для складних та довготривалих застосунків. Приймаючи принципи інверсії залежностей та чітких інтерфейсів, ви можете створювати системи, які є більш стійкими, легшими для розуміння та краще підготовленими до вимог сучасного програмного ландшафту.

Цей посібник надав всебічний огляд гексагональної архітектури, від її основних принципів до практичних стратегій реалізації. Ми заохочуємо вас досліджувати ці концепції далі та експериментувати з їх застосуванням у ваших власних проєктах. Інвестиції у вивчення та впровадження гексагональної архітектури, безсумнівно, окупляться в довгостроковій перспективі, що призведе до вищої якості програмного забезпечення та більш задоволених команд розробників.

Зрештою, вибір правильної архітектури залежить від конкретних потреб вашого проєкту. Враховуйте складність, довговічність та вимоги до супроводу при прийнятті рішення. Гексагональна архітектура надає міцну основу для створення надійних та адаптивних застосунків, але це лише один інструмент в арсеналі архітектора програмного забезпечення.